fix(k8s): read traffic manager port from provider traffic_manager group - #219

Summary

Moves the provider read path for the traffic-manager listener port from .cluster.main_traffic_manager_port to .traffic_manager.port, so it matches where the EKS provider spec declares it.

Without this, the feature released in 1.15.0 does nothing when set through the provider — the provider stores the value under traffic_manager.port and the scope reads a different location, so resolution silently falls through to the 80 default.

Why the path changed

The scope reads container-orchestration values by the provider spec's structural path, not by the NRN key name. Confirmed against every existing read: spec balancer.public_name → .balancer.public_name, spec cluster.namespace → .cluster.namespace.

The EKS provider spec already has a traffic_manager group holding version (mapped to k8s.trafficManagerContainerTag). The port belongs beside it, not in cluster next to id / namespace / use_nullplatform_namespace. The new property is declared as traffic_manager.port → k8s.mainTrafficManagerPort (nullplatform/main-nrn-api#193).

Changes

• k8s/deployment/build_context:290 — one --provider path. The scope-configurations path (.deployment.main_traffic_manager_port) is unchanged; that provider has its own naming convention and sits beside deployment.traffic_manager_config_map.
• k8s/deployment/tests/build_context.bats — 10 occurrences updated. The context field name, the env var, the validation and every error message stay exactly as they were; only the provider location moved.
• k8s/docs/configurable-http-ports.md — the documented provider path, and the adoption steps now name the Traffic Manager Port field on the EKS provider.

No CHANGELOG entry: this goes out overwriting the 1.15.0 release published yesterday, whose entry already covers the feature.

Safe to change

main_traffic_manager_port shipped yesterday in 1.15.0 and has no adopters — the provider property that would let anyone set it is only being added now, in nullplatform/main-nrn-api#193. So there is no configured value anywhere to migrate, and nothing to keep backwards-compatible.

Test plan

• bats k8s/deployment/tests/build_context.bats k8s/deployment/tests/traffic_manager_port_shape.bats → 82/82 pass.
• grep -rn "cluster.main_traffic_manager_port" k8s/ returns nothing.
• The scope-configurations provider path is still present exactly once, and its precedence over container-orchestration is still covered by main_traffic_manager_port: scope-configurations takes priority over container-orchestration.

Relationship to #218

#218 also modifies k8s/deployment/tests/build_context.bats, but the two changes are in disjoint regions of the file and merge cleanly in either order — verified, not assumed:

• test(k8s): assert complete log messages in deployment tests #218 touches lines 33–121 (the validate_status debug-line assertions) and 560–620 (two full-script error tests).
• This PR touches lines 1064–1223 (the main_traffic_manager_port tests' jq provider path).

#218 deliberately left the main_traffic_manager_port tests untouched, since #216 had already put them in full-error-block form. No conflict resolution is needed.